home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / filetran / uucpprot.doc < prev    next >
Internet Message Format  |  1991-10-27  |  29KB
  1. From: brian@sdcsvax.UCSD.EDU (Brian Kantor)
  2. Newsgroups: comp.doc
  3. Subject: UUCP Protocol Information Potpourri
  4. Date: 20 Jan 88 02:04:02 GMT
  5.  
  6. The following is collection of stuff that John Gilmore posted to the net
  7. some time ago; with renewed interest in making nearly everything under
  8. the sun talk uucp, I figured it was time this document appeared somewhere 
  9. that it would get archived for future inquiries.
  10.  
  11. From ucsdhub!hp-sdd!hplabs!decwrl!sun!hoptoad!gnu Tue Feb  3 13:10:08 PST 1987
  12.  
  13. [This information came from the Tanner Andrews's uucpinfo mailing list.
  14. This is a collection of people interested in writing a version
  15. of uucp in the public domain.  Contact ihnp4!akgua!ucf-cs!ki4pv!tanner
  16. to be added to the mailing list.  There have only been three messages
  17. sent to the list; all are below.
  18.  
  19.     John Gilmore, hoptoad!gnu]
  20.  
  21. -----
  22.  
  23. Subject: UUCP Protocol Information (issue #1)
  24. Date: Tue Nov 19 22:04:56 1985
  25.  
  26. Greetings.  First order of business is the fact that I probably have
  27. a lousy or a slow address for some of you all.  Please complain, and
  28. things will be corrected.  Those of you not receiving this because your
  29. names have been omitted will please inform me, giving a good address.
  30. Those who provided replies but who are not interested in receiving
  31. further information please warn me; maybe things won't cross in the
  32. mail.
  33.  
  34. Now that we're over that, welcome to the first issue.  There will most
  35. likely be more, as more information is received.  Anyone with comments,
  36. information, or clean suggestions to be shared should please write to
  37. me at the return address given below.  I'll keep the copy of this
  38. mailing list around, and make required additions, deletions, &c.  This
  39. issue is just a "welcome" and mailing-error-finder.  Sorry about the
  40. delay between your "me-too" mailing and the actual goodstuff.
  41.  
  42. This is being issued as a mailing list because, while I have some of
  43. the required information, there is still rather a shortage.  Research
  44. is expected to improve the situation.
  45.  
  46. The second issue of this will be coming out almost immediately, and
  47. will contain the bulk of the preliminary information which I have.
  48. It will also include a summary which has been tempered by experience
  49. on this system (type ~uucp_adm/uucico on my terminal, watch the fun
  50. begin).
  51.  
  52. My address is:
  53.     uucp:    ...{decvax|akgua}!ucf-cs!ki4pv!tanner
  54.     csnet:    ki4pv!tanner@ucf-cs.csnet
  55.     arpa:    ki4pv!tanner%ucf-cs.csnet@csnet-relay.arpa
  56.  
  57.                         Tanner Andrews, systems
  58.                         CompuData South,
  59.                         P.O.Box 3636,
  60.                         DeLand, FLA   32723.
  61.  
  62. >From: ihnp4!akgua!ucf-cs!ki4pv!tanner
  63. To: ucf-cs!ki4pv-uucpinfo2, ucf-cs!ki4pv-uucpinfo1
  64. Subject: UUCP Information Issue #02
  65. Date: Wed Dec 11 23:39:26 1985
  66.  
  67. This is the second issue; the information below is the start of
  68. what has been collected here.  It is expected that more information
  69. will be collected in the next few weeks, and that information will
  70. be forwarded when/if it becomes available.
  71.  
  72.  =====================================================
  73.  -- part 1
  74.  =====================================================
  75. This information came via several people, most of whom snet this
  76. exact message (probably from their news archives from before we
  77. joined the net):
  78.  
  79.     I am posting this over the network because I believe that
  80.     others are interested in knowing the protocols of UUCP.
  81.     Below is listed all the information that I have acquired
  82.     to date. This includes the initial handshaking phase, though
  83.     not the login phase. It also doesn't include information
  84.     about the data transfer protocol for non-packet networks
  85.     (the -G option left off the uucico command line). But, just
  86.     hold on - I am working on that stuff.
  87.  
  88.     For a point of information : the slave is the UUCP site being
  89.     dialed, and the master is the one doing the calling up. The
  90.     protocols listed in the handshaking and termination phase are
  91.     independent of any UUCP site : it is universal. The stuff in
  92.     the work phase depends on the specific protocol chosen. The
  93.     concepts in the work phase are independent of protocol, ie. the
  94.     sequences are the same. It is just the lower level stuff that
  95.     changes from protocol to protocol. I have access only to level
  96.     g and will document it as I begin to understand it.
  97.  
  98.     Most of the stuff you see here is gotten from the debug phase
  99.     of the current BSD UUCP system.
  100.  
  101.     I hope this is useful. Maybe this will get some of the real
  102.     'brains' in UUCP to get off their duffs and provide some real
  103.     detail. In any case, if you have any questions please feel
  104.     free to contact me. I will post any questions and answers over
  105.     the network.
  106.  
  107.  
  108.                 Chuck Wegrzyn
  109.                 {allegra,decvax,ihnp4}!encore!wegrzyn
  110.  
  111.                 (617) 237-1022
  112.  
  113.  
  114.  
  115.             UUCP Handshake Phase
  116.             ====================
  117.  
  118. Master                            Slave
  119. ------                            -----
  120.  
  121.                     <-----        \020Shere\0     (1)
  122.  
  123.  
  124. (2)  \020S<mastername> <switches>\0    ----->
  125.  
  126.  
  127.                     <-----        \020RLCK\0      (3)
  128.                             \020RCB\0
  129.                             \020ROK\0
  130.                             \020RBADSEQ\0
  131.  
  132.                     <-----        \020P<protos>\0 (4)
  133.  
  134.  
  135. (5) \020U<proto>\0            ----->
  136.     \020UN\0
  137.  
  138.  
  139. (6) ...
  140.  
  141.  
  142. (0) This communication happens outside of the packet communication that
  143.     is supported. If the -G flag is sent on the uucico line, all
  144.     communications will occur without the use of the packet
  145.     simulation software. The communication at this level is just
  146.     the characters listed above.
  147.  
  148. (1) The slave sends the sequence indicated, while the master waits for
  149.     the message.
  150.  
  151. (2) The slave waits for the master to send a response message. The message
  152.     is composed of the master's name and some optional switches.
  153.     The switch field can include the following
  154.  
  155.             -g        (set by the -G switch on the
  156.                      master's uucico command line.
  157.                      Indicates that communication
  158.                      occurs over a packet switch net.)
  159.             -xN        (set by the -x switch on the
  160.                      master's uucico command line.
  161.                      The number N is the debug level
  162.                      desired.)
  163.             -QM        (M is really a sequence number
  164.                      for the communication.)
  165.  
  166.     Each switch is separated from the others by a 'blank' character.
  167.  
  168. (3) The slave will send one of the many responses. The meanings appear to
  169.     be :
  170.  
  171.     RLCK
  172.  
  173.         This message implies that a 'lock' failure occurred:
  174.         a file called LCK..mastername couldn't be created since
  175.         one already exists. This seems to imply that the master
  176.         is already in communication with the slave.
  177.  
  178.     RCB
  179.  
  180.         This message will be sent out if the slave requires a
  181.         call back to the master - the slave will not accept a
  182.         call from the master but will call the master instead.
  183.  
  184.     ROK
  185.  
  186.         This message will be returned if the sequence number that
  187.         was sent in the message, attached to the -Q switch, from 
  188.         the master is the same as that computed on the slave.
  189.  
  190.     RBADSEQ
  191.  
  192.         Happens if the sequence numbers do not match.
  193.  
  194.     (Notes on the sequence number - if a machine does not keep
  195.      sequence numbers, the value is set to 0. If no -Q switch
  196.      is given in the master's line, the sequence number is
  197.      defaulted to 0.
  198.  
  199.      The sequence file, SQFILE, has the format
  200.  
  201.         <remotename> <number> <month>/<day>-<hour>:<min>
  202.  
  203.      where <remotename> is the name of a master and <number>
  204.      is the previous sequence number. If the <number> field
  205.      is not present, or if it is greater than 9998, it is
  206.      set to 0. The <number> field is an ascii representation
  207.      of the number. The stuff after the <number> is the time
  208.      the sequence number was last changed, this information
  209.      doesn't seem important.)
  210.  
  211. (4) The slave sends a message that identifies all the protocols that
  212.     it supports. It seems that BSD supports 'g' as the normal case.
  213.     Some sites, such as Allegra, support 'e' and 'g', and a few
  214.     sites support 'f' as well. I have no information about these
  215.     protocols. The exact message sent might look like
  216.  
  217.         \020Pefg\0
  218.  
  219.     where efg indicates that this slave supports the e,f and g 
  220.     protocols.
  221.  
  222. (5) The slave waits for a response from the master with the chosen
  223.     protocol. If the master has a protocol that is in common the
  224.     master will send the message
  225.  
  226.         \020U<proto>\0
  227.  
  228.     where <proto> is the protocol (letter) chosen. If no protocol
  229.     is in common, the master will send the message
  230.  
  231.         \020UN\0
  232.  
  233. (6) At this point both the slave and master agree to use the designated
  234.     protocol. The first thing that now happens is that the master
  235.     checks for work.
  236.  
  237. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  238.  
  239.             UUCP Work Phase
  240.             ===============
  241.  
  242.  
  243. Master                            Slave
  244. ------                            -----
  245.  
  246. (a) Master has UUCP Work
  247.  
  248.     (1) X file1 file2     ----->
  249.  
  250.                     <-----        XN        (2)
  251.                             XY
  252.  
  253.     When the master wants the slave to do a 'uux' command
  254.     it sends the X message. If the slave can't or won't
  255.     do it, the slave will send an XN message. Otherwise
  256.     it will send an XY message.
  257.  
  258. (b) Master wants to send a file
  259.  
  260.     (1) S file1 file2 user options  ----->
  261.  
  262.                     <-----        SN2        (2)
  263.                             SN4
  264.                             SY
  265.  
  266.             <---- <data exchanged>---->            (3)
  267.  
  268.  
  269.                     <-----        CY        (4)
  270.                             CN5
  271.  
  272.     If the master wishes to send a file to the slave, it will
  273.     send a S message to the slave. If the slave can or will do
  274.     the transfer, it sends a SY message. If the slave has a
  275.     problem creating work files, it sends a SN4 message. If
  276.     the target file can't be created (because of priv's etc)
  277.     it sends a SN2 message.
  278.  
  279.     The file1 argument is the source file, and file2 is the
  280.     (almost) target filename. If file2 is a directory, then
  281.     the target filename is composed of file2 concatenated
  282.     with the "last" part of the file1 argument. Note, if the
  283.     file2 argument begins with X, the request is targeted to
  284.     UUX and not the normal send.
  285.  
  286.     The user argument indicates who, if anyone, is to be notified
  287.     if the file has been copied. This user must be on the slave
  288.     system.
  289.  
  290.     I am not sure what the options argument does.
  291.  
  292.     After the data has been exchanged the slave will send one of
  293.     two messages to the master. A CY message indicates that every-
  294.     thing is ok. The message CN5 indicates that the slave had
  295.     some problem moving the file to it's permanent location. This
  296.     is not the same as a problem during the exchange of data : this
  297.     causes the slave to terminate operation.
  298.  
  299. (c) Master wishes to receive a file.
  300.  
  301.     (1) R file1 file2 user    ----->
  302.  
  303.                         <-----    RN2        (2)
  304.                             RY mode
  305.  
  306.     (3)        <---- <data exchanged> ---->
  307.  
  308.     (4)    CY        ----->
  309.         CN5
  310.  
  311.     If the master wishes the slave to send a file, the master sends
  312.     a R message. If the slave has the file and can send it, the
  313.     slave will respond with the RY message. If the slave can't find
  314.     the file, or won't send it the RN2 message is sent. It doesn't
  315.     appear that the 'mode' field of the RY message is used.
  316.  
  317.     The argument file1 is the file to transfer, unless it is a
  318.     directory. In this case the file to be transferred is built
  319.     of a concatenation of file1 with the "last" part of the file2
  320.     argument.
  321.  
  322.     If anything goes wrong with the data transfer, it results in
  323.     both the slave and the master terminating.
  324.  
  325.     After the data has been transferred, the master will send an
  326.     acknowledgement to the slave. If the transfer and copy to the
  327.     destination file has been successful, the master will send the
  328.     CY message. Otherwise it will send the CN5 message.
  329.  
  330. (d) Master has no work, or no more work.
  331.  
  332.     (1) H            ----->
  333.  
  334.                 <-----                HY    (2)
  335.                                 HN
  336.  
  337.     (3) HY            ----->
  338.  
  339.                 <----                HY    (4)
  340.  
  341.     (5) ...
  342.  
  343.     The transfer of control is initiated with the master sending
  344.     a H message. This message tells the slave that the master has
  345.     no work, and the slave should look for work.
  346.  
  347.     If the slave has no work it will respond with the HY message.
  348.     This will tell the master to send an HY message, and turn off
  349.     the selected protocol. When the HY message is received by the
  350.     slave, it turns off the selected protocol as well. Both the
  351.     master and slave enter the UUCP termination phase.
  352.  
  353.     If the slave does have work, it sends the HN message to the
  354.     master. At this point, the slave becomes the master. After
  355.     the master receives the HN message, it becomes the slave.
  356.     The whole sequence of sending work starts over again. Note,
  357.     the transmission of HN doesn't force the master to send any
  358.     other H messages : it waits for stuff  from the new master.
  359.  
  360. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  361.  
  362.  
  363.             UUCP Termination Sequence
  364.             =========================
  365.  
  366.  Master                                Slave
  367.  ------                                -----
  368.  
  369.  (1) \020OOOOOO\0        ----->
  370.  
  371.                 <-----            \020OOOOOOO\0 (2)
  372.  
  373.  
  374.  
  375.     At this point all conversation has completed normally.
  376.  
  377.  
  378. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  379.  
  380.             UUCP Data Transfers
  381.             ===================
  382.  
  383.     After the initial handshake the systems send messages in one
  384.     of two styles : packet and not packet. A Packet protocol is
  385.     just raw data transfers : there is no protocol or acknowledgements;
  386.     this appears to assume that the lower level is a packet network
  387.     of some type. If the style is not Packet, then extra work is
  388.     done. I am still working on this stuff.
  389.  
  390.  =====================================================
  391.  -- part 2
  392.  =====================================================
  393.  ** summary of UUCP packets ** 
  394. (this is much like part 1, but shortened and compared against a
  395. live UUCP ~uucp_adm/uucico)
  396.  
  397. note that all transmissions end with a null, not shown here
  398.  
  399.  
  400. (master)        (slave)
  401.  
  402.  ... dials up ...    <DLE>Shere        says "hello"
  403.  
  404. <DLE>S<sysname> <opts>                says who he is
  405.  
  406.         |    <DLE>ROK        says ok to talk
  407.         |    <DLE>RLCK        says locked out
  408.         |    <DLE>RCB        says will call back
  409.         |    <DLE>RBADSEQ        says bad seq num
  410.  
  411.             <DLE>P<protos>        what protocols he has
  412.  
  413. <DLE>U<proto>    |                which to use
  414. <DLE>UN        |                use none, hang up
  415.  
  416.  
  417. packet driver is turned on at this time, if not told otherwise
  418.  
  419.  -- if master has work --
  420.  
  421. to sned file to slave...
  422. S <mfilenm> <sfilenm> <user> <opts>        request to sned file
  423.  
  424.         |    SY            ok -- i'll take it
  425.         |    SN2            not permitted
  426.         |    SN4            can't make workfile
  427.  
  428. <data>                        the file is transmitted
  429.  
  430.         |    CY            finished OK
  431.         |    CN5            can't move into place
  432.  
  433.  
  434. to recv file from slave...
  435. R <sfilenm> <mfilenm> <user>            request to recv file
  436.  
  437.         |    RY<mode>        ok -- here is prot mode
  438.         |    RN2            not permitted
  439.  
  440.             <data>            file is transmitted
  441.  
  442. CY        |                worked
  443. CN5        |                can't move into place
  444.  
  445.  
  446. to do UUX on slave...
  447. X <file1> <file2>                request to exec file
  448.  
  449.         |    XY            ok -- will do
  450.         |    XN            nopers
  451.  
  452. to indicate that he has no more work...
  453. H                        no more work
  454.  
  455.         |    HN            reverse roles
  456.         |    HY            no work here either
  457.  
  458. to accept slave's claim of no more work...
  459.  
  460. HY                        agrees to hang up
  461.  
  462. the rest of the hang-up is done OUTSIDE of packet driver
  463. <DLE>OOOOOO                    signs off (6*'O')
  464.  
  465.             <DLE>OOOOOOO        signs off (7*'O')
  466.     
  467.  
  468. If the slave has work, then the roles are reversed, and the
  469. session proceeds from the label 'loop1' above.  The system
  470. which was the slave is now the master, and the old master is
  471. just the slave.
  472.  
  473. The <opts> which follow the system name for the start-up sequence
  474. include:
  475.     -g        don't use packet driver (command line -G)
  476.     -xN        debug level (command line -Xn)
  477.     -QN        seq number (if systems use this)
  478.  
  479. The filenames for <mfilenm> should be complete filenames with
  480. path information; otherwise they are assumed to be in /usr/spool/uucp.
  481. The filenames for <sfilenm> should be either complete filenames
  482. or directory names.  If directory names are used, then the final
  483. componant of <mfilenm> is appended to form the complete filename.
  484.  
  485. The 'X' command to do UUX on a slave is more than a little unclear.
  486. It doesn't seem to work here, but that may be a microsoft "feature".
  487.  
  488.  
  489. Protocol "g", which seems to be the one most commonly used, is supposed
  490. to be a slightly munged version of level 2 of X.25; an article was just
  491. posted in net.unix-wizards (which you probably have already seen) to
  492. this effect.  The article didn't provide any details on the protocol,
  493. but merely mentioned the modifications.
  494.  
  495. The "packet" mode, with no protocol, does not work under microsoft
  496. implementations, and may have *lots* of trouble working anywhere
  497. else as well.  It evidently requires that zero-length reads happen
  498. every so often to delimit things, such as files being transferred.
  499. This of course can't happen without the packet driver, which was long
  500. gone by the time sys-3 or sys-5 or <your current version> came along.
  501.  
  502. **********************************
  503. ** end of issue #2
  504. **********************************
  505.  
  506.  
  507. >From: ihnp4!akgua!ucf-cs!ki4pv!tanner
  508. To: ucf-cs!ki4pv-uucpinfo, allegra!mp
  509. Subject: UUCP INFO mailing list issue #03
  510. Date: Sun Jan 12 19:11:18 1986
  511.  
  512. The following information, describing the uucp 'g' protocol, was
  513. provided as "nroff" source.  Cut the header and this text off of
  514. the message, and run it through "nroff".
  515. .ce
  516. .B
  517. Packet Driver Protocol
  518. .R
  519. .sp 1
  520. .ce
  521. G. L. Chesson
  522. .br
  523. .ce
  524. Bell Laboratories
  525. .SH
  526. Abstract
  527. .in +.5i
  528. .PP
  529. These notes describe the packet driver link
  530. protocol that was supplied
  531. with the
  532. Seventh Edition of
  533. .UX
  534. and is used by the UUCP program.
  535. .in -.5i
  536. .SH
  537. General
  538. .PP
  539. Information flow between a pair of machines
  540. may be regulated by
  541. first
  542. representing the data 
  543. as sequence-numbered 
  544. .I
  545. packets
  546. .R
  547. of data 
  548. and then establishing conventions that
  549. govern the use of sequence numbers.
  550. The
  551. .I
  552. PK,
  553. .R
  554. or
  555. .I
  556. packet driver,
  557. .R
  558. protocol
  559. is a particular instance of this type of
  560. flow-control discipline.
  561. The technique depends on the notion of a transmission
  562. .I
  563. window
  564. .R
  565. to determine upper and lower bounds for valid
  566. sequence numbers.
  567. The transmitter is allowed to retransmit packets
  568. having sequence numbers
  569. within the window until the receiver indicates that
  570. packets have been correctly received.
  571. Positive acknowledgement from the receiver moves the
  572. window;
  573. negative acknowledgement or no acknowledgement
  574. causes retransmission.
  575. The receiver must ignore duplicate transmission, detect
  576. the various errors that may occur,
  577. and inform the transmitter when packets are 
  578. correctly or incorrectly received.
  579. .PP
  580. The following paragraphs describe the packet formats,
  581. message exchanges,
  582. and framing
  583. used by the protocol as coded
  584. in the UUCP program and the
  585. .UX
  586. kernel.
  587. Although no attempt will be made here to present
  588. internal details of the algorithms that were used,
  589. the checksum routine is supplied
  590. for the benefit of other implementors.
  591. .SH
  592. Packet Formats
  593. .PP
  594. The protocol is defined in terms of message
  595. transmissions of 8-bit bytes.
  596. Each message includes one
  597. .I
  598. control
  599. .R
  600. byte plus a
  601. .I
  602. data segment
  603. .R
  604. of zero or more information bytes.
  605. The allowed data segment sizes range
  606. between 32 and 4096 as determined by the formula
  607. 32(2\uk\d) where
  608. k is a 3-bit number.
  609. The packet sequence numbers are likewise constrained
  610. to 3-bits; i.e. counting proceeds modulo-8.
  611. .PP
  612. The control byte is partitioned into three fields as
  613. depicted below.
  614. .bp
  615. .nf
  616. .sp 
  617. .in 1i
  618. .ls 1
  619. bit    7    6    5    4    3    2    1    0
  620.     t    t    x    x    x    y    y    y
  621. .ls 1
  622. .in -1i
  623. .fi
  624. .sp
  625. The
  626. .I
  627. t
  628. .R
  629. bits indicate a packet type and
  630. determine the interpretation to be placed on
  631. the
  632. .I
  633. xxx
  634. .R
  635. and
  636. .I
  637. yyy
  638. .R
  639. fields.
  640. The various interpretations are as follows:
  641. .in +1i
  642. .sp
  643. .nf
  644. .ls 1
  645. .I
  646. tt    interpretation
  647. .sp
  648. .R
  649. 00    control packet
  650. 10    data packet
  651. 11    `short' data packet
  652. 01    alternate channel
  653. .ls 1
  654. .fi
  655. .sp
  656. .in -1i
  657. A data segment accompanies all non-control packets.
  658. Each transmitter is constrained to observe the maximum
  659. data segment size
  660. established during initial synchronization by the
  661. receiver that it sends to.
  662. Type 10 packets have maximal size data segments.
  663. Type 11, or `short', packets have zero or more data
  664. bytes but less than the maximum.
  665. The first one or two bytes of the data segment of a
  666. short packet are `count' bytes that
  667. indicate the difference between the
  668. maximum size and the number of bytes in the short
  669. segment.
  670. If the difference is less than 127, one count
  671. byte is used.
  672. If the difference exceeds 127,
  673. then the low-order seven bits of the difference
  674. are put in the first data byte and the high-order
  675. bit is set as an indicator that the remaining
  676. bits of the difference are in the second byte.
  677. Type 01 packets are never used by UUCP
  678. and need not be discussed in detail here.
  679. .PP
  680. The sequence number of a non-control packet is
  681. given by the
  682. .I
  683. xxx
  684. .R
  685. field.
  686. Control packets are not sequenced.
  687. The newest sequence number,
  688. excluding duplicate transmissions,
  689. accepted by a receiver is placed in the
  690. .I
  691. yyy
  692. .R
  693. field of non-control packets sent to the
  694. `other' receiver.
  695. .PP
  696. There are no data bytes associated with a control packet,
  697. the
  698. .I
  699. xxx
  700. .R
  701. field is interpreted as a control message,
  702. and the
  703. .I
  704. yyy
  705. .R
  706. field is a value accompanying the control message.
  707. The control messages are listed below in decreasing priority.
  708. That is, if several control messages are to be sent,
  709. the lower-numbered ones are sent first.
  710. .in +1i
  711. .nf
  712. .ls 1
  713. .sp
  714. .I
  715. xxx    name        yyy
  716. .R
  717.  
  718. 1    CLOSE    n/a
  719. 2    RJ        last correctly received sequence number
  720. 3    SRJ        sequence number to retransmit
  721. 4    RR        last correctly received sequence number
  722. 5    INITC    window size
  723. 6    INITB    data segment size
  724. 7    INITA    window size
  725. .in -i
  726. .ls 1
  727. .fi
  728. .sp
  729. .PP
  730. The CLOSE message indicates that the communications channel
  731. is to be shut down.
  732. The RJ, or
  733. .I
  734. reject,
  735. .R
  736. message indicates that the receiver has detected an error
  737. and the sender should retransmit after using the 
  738. .I
  739. yyy
  740. .R
  741. field to update the window.
  742. This mode of retransmission is usually
  743. referred to as a
  744. `go-back-N' procedure.
  745. The SRJ, or
  746. .I
  747. selective reject,
  748. .R
  749. message carries with it the sequence number of
  750. a particular packet to be retransmitted.
  751. The RR, or
  752. .I
  753. receiver ready,
  754. .R
  755. message indicates that the receiver has detected
  756. no errors; the
  757. .I
  758. yyy
  759. .R
  760. field updates the sender's window.
  761. The INITA/B/C messages are used
  762. to set window and data segment sizes.
  763. Segment sizes are calculated by the formula
  764. 32(2\uyyy\d)
  765. as mentioned above,
  766. and window sizes may range between 1 and 7.
  767. .PP
  768. Measurements of the protocol running on communication
  769. links at rates up to 9600 baud showed that
  770. a window size of 2 is optimal
  771. given a packet size greater than 32 bytes.
  772. This means that the link bandwidth can be fully utilized
  773. by the software.
  774. For this reason the SRJ message is not as important as it
  775. might otherwise be.
  776. Therefore the
  777. .UX
  778. implementations no longer generate or respond to SRJ
  779. messages.
  780. It is mentioned here for historical accuracy only,
  781. and one may assume that SRJ is no longer part of the protocol.
  782. .SH
  783. Message Exchanges
  784. .SH
  785.     Initialization
  786. .PP
  787. Messages are exchanged between four cooperating
  788. entities: two senders and two receivers.
  789. This means that the communication channel is thought of
  790. as two independent half-duplex data paths.
  791. For example the window and segment sizes need not
  792. be the same in each direction.
  793. .PP
  794. Initial synchronization is accomplished
  795. with two 3-way handshakes: two each of
  796. INITA/INITB/INITC.
  797. Each sender transmits INITA messages repeatedly.
  798. When an INITA message is received, INITB is
  799. sent in return.
  800. When an INITB message is received
  801. .I
  802. and
  803. .R
  804. an INITB message has been sent,
  805. an INITC message is sent.
  806. The INITA and INITB messages carry 
  807. with them the packet and window size that
  808. each receiver wants to use,
  809. and the senders are supposed to comply.
  810. When a receiver has seen all three
  811. INIT messages, the channel is 
  812. considered to be open.
  813. .PP
  814. It is possible to design a protocol that starts up using
  815. fewer messages than the interlocked handshakes described above.
  816. The advantage of the more complicated design lies in its use as
  817. a research vehicle:
  818. the initial handshake sequence is completely symmetric,
  819. a handshake
  820. can be initiated by one side of the link while the
  821. connection is in use, and the software to do this can
  822. utilize code that would ordinarily be used only once
  823. at connection setup time.
  824. These properties were used in experiments with dynamically
  825. adjusted parameters.
  826. That is attempts were made to adapt the window and segment
  827. sizes to changes observed in traffic while a link was in use.
  828. Other experiments used the initial
  829. handshake  in a different way
  830. for restarting the protocol without data loss
  831. after machine crashes.
  832. These experiments never worked well in the packet driver and
  833. basically provided the impetus for other protocol designs.
  834. The result 
  835. as far as UUCP is concerned is that initial synchronization
  836. uses the two 3-way handshakes, and the INIT
  837. messages are ignored elsewhere.
  838. .SH
  839.     Data Transport
  840. .PP
  841. After initial synchronization each receiver
  842. sets a modulo-8 incrementing counter R to 0;
  843. each sender sets a similar counter S to 1.
  844. The value of R is always the number of the most recent
  845. correctly received packet.
  846. The value of S is always the first sequence number in
  847. the output window.
  848. Let W denote window size.
  849. Note that the value of W may be different for each sender.
  850. .PP
  851. A sender may transmit packets with sequence numbers
  852. in the range S to (S+W-1)\ mod-8.
  853. At any particular time a receiver expects
  854. arriving packets to have numbers in the range
  855. (R+1)\ mod-8 to (R+W)\ mod-8.
  856. Packets must arrive in sequence number order
  857. are are only acknowledged in order.
  858. That is,
  859. the `next' packet a receiver
  860. will acknowledge must have
  861. sequence number (R+1)\ mod-8.
  862. .PP
  863. A receiver acknowledges receipt of data packets
  864. by arranging for the value of its R counter to be
  865. sent across the channel
  866. where it will be used to update an S counter.
  867. This is done in two ways.
  868. If data is flowing in both directions across a
  869. channel then each receiver's current R value is
  870. carried in the
  871. .I
  872. yyy
  873. .R
  874. field of non-control packets.
  875. Otherwise when there is no bidirectional
  876. data flow,
  877. each receiver's R value is transmitted across the link
  878. as the
  879. .I
  880. yyy
  881. .R
  882. field of an RR control packet.
  883. .PP
  884. Error handling is up to the discretion
  885. of the receiver.
  886. It can ignore all errors in which case
  887. transmitter timeouts must provide for
  888. retransmission.
  889. The receiver may also generate RJ 
  890. error control packets.
  891. The
  892. .I
  893. yyy
  894. .R
  895. field of an incoming RJ message replaces
  896. the S value of the local sender and
  897. constitutes a request for retransmission to start
  898. at that sequence number.
  899. The
  900. .I
  901. yyy
  902. .R
  903. field of an incoming SRJ message selects a particular
  904. packet for retransmission.
  905. .PP
  906. The resemblance between the flow control procedure in the
  907. packet driver and that defined for X.25 is no accident.
  908. The packet driver protocol began life as an attempt at
  909. cleaning up X.25.
  910. That is why, for example,
  911. control information is uniform in length (one byte),
  912. there is no RNR message (not needed),
  913. and there is but one timeout defined
  914. in the sender.
  915. .SH
  916.     Termination
  917. .PP
  918. The CLOSE message is used to terminate communications.
  919. Software on either or both ends of the communication
  920. channel may initiate termination.
  921. In any case when one end wants to terminate it sends
  922. CLOSE messages until one is received from the other end
  923. or until a programmable limit on the number of CLOSE
  924. messages is reached.
  925. Receipt of a CLOSE message causes a CLOSE message to be sent.
  926. In the 
  927. .UX
  928. environment
  929. it also causes the SIGPIPE or
  930. `broken pipe' signal to be sent to
  931. the local process using the communication channel.
  932. .SH
  933.     Framing
  934. .PP
  935. The term
  936. .I
  937. framing
  938. .R
  939. is used to denote the technique by which the
  940. beginning and end of a message is detected
  941. in a byte stream;
  942. .I
  943. error control
  944. .R
  945. denotes the method by which transmission
  946. errors are detected.
  947. Strategies for framing and error control depend
  948. upon
  949. additional information being transmitted along
  950. with the control byte and data segment,
  951. and the choice of a particular strategy usually
  952. depends on characteristics of input/output
  953. devices and transmission media.
  954. .PP
  955. Several framing techniques are in used in support
  956. of PK protocol implementations,
  957. not all of which can be described in detail here.
  958. The technique used on asynchronous serial lines
  959. will be described.
  960. .PP
  961. A six byte
  962. framing
  963. .I
  964. envelope
  965. .R
  966. is constructed using the control byte
  967. C of a packet and five other bytes as
  968. depicted below.
  969. .in +1i
  970. <DLE><k><c0><c1><C><x>
  971. .in -1i
  972. The <DLE> symbol denotes the ASCII ctrl/P character.
  973. If the envelope is to be followed by a data segment,
  974. <k> has the value
  975. log\d2\u(size)-4;
  976. i.e. 1 \(<= k \(<= 8.
  977. If k is 9, then the envelope represents a control packet.
  978. The <c0> and <c1> bytes are the low-order and high-order
  979. bytes respectively of a 16-bit checksum of the data segment,
  980. if there is one.
  981. For control packets <c1> is zero and <c0> is the same
  982. as the control byte C.
  983. The <x> byte is the exclusive-or of <k><c0><c1><C>.
  984. Error control is accomplished by checking 
  985. a received framing envelope for compliance with the definition,
  986. and comparing a checksum function of the data segment
  987. with <c0><c1>.
  988. .PP
  989. This particular framing strategy assumes data segments
  990. are constant-sized:
  991. the `unused' bytes in a short packet are actually
  992. transmitted.
  993. This creates a certain amount of overhead which
  994. can be eliminated by a more complicated framing technique.
  995. The advantage of this strategy is that i/o
  996. devices can be programmed to take advantage of the
  997. constant-sized framing envelopes and data segments.
  998. .bp
  999. .PP
  1000. The checksum calculation is displayed below as a C function.
  1001. Note that the code is not truly portable because
  1002. the definitions of
  1003. .I short
  1004. and
  1005. .I char
  1006. are not necessarily uniform across all machines
  1007. that might support this language.
  1008. This code assumes that
  1009. .I short
  1010. and
  1011. .I char
  1012. are 16 and 8-bits respectively.
  1013. .PP
  1014. .in +.5i
  1015. .nf
  1016. .ft CW
  1017. .ls 1
  1018. /* [Original document's version corrected to actual version] */
  1019. chksum(s,n)
  1020. register char *s;
  1021. register n;
  1022. {
  1023.     register short sum;
  1024.     register unsigned short t;
  1025.     register short x;
  1026.  
  1027.     sum = -1;
  1028.     x = 0;
  1029.  
  1030.     do {
  1031.         if (sum<0) {
  1032.             sum <<= 1;
  1033.             sum++;
  1034.         } else
  1035.             sum <<= 1;
  1036.         t = sum;
  1037.         sum += (unsigned)*s++ & 0377;
  1038.         x += sum^n;
  1039.         if ((unsigned short)sum <= t) {
  1040.             sum ^= x;
  1041.         }
  1042.     } while (--n > 0);
  1043.  
  1044.     return(sum);
  1045. }
  1046. .fi
  1047. .in -.5i
  1048. .ft R
  1049. -- 
  1050. John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   gnu@ingres.berkeley.edu
  1051. Love your country but never trust its government.
  1052.              -- from a hand-painted road sign in central Pennsylvania
  1053.